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ABSTRACT 

The  introduction  of  Asynchronous  Transfer  Mode  (ATM)  into  the  Australian  Army 
tactical  communication  system  will  provide  significant  benefits  through  responsive 
network  management  and  the  integration  of  multiple  communication  applications. 
ATM  integration  into  Parakeet  is  complicated  as  the  current  network  employs  military 
standard  protocols  which  are  quite  different  to  civil  standards.  This  report  seeks  to 
quantify  capacity  economies  which  can  be  achieved  through  the  development  of  an 
adaptive  approach  to  voice  services  on  the  ATM  network  by  transmitting  only  active 
connections.  An  examination  is  also  made  to  determine  whether  data  communications 
protocols  can  access  the  released  capacity.  The  study  finds  that  savings  are  significant 
and  the  released  capacity  should  add  substantially  to  data  communications  capability. 
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A  Case  for  Call  Activity  Detection  for  ATM 
Voice  Services  in  Project  Parakeet 


Executive  Summary 

The  introduction  of  Asynchronous  Transfer  Mode  (ATM)  into  the  Australian  Army 
tactical  communication  system  will  provide  significant  benefits  through  responsive 
network  management  and  the  integration  of  multiple  communication  applications. 
Integration  of  ATM  with  the  current  system  (Parakeet)  is  complicated  by  the  fact  that 
Parakeet  employs  military  standard  protocols  which  are  quite  different  to  civil 
standards. 

This  report  shows  the  significant  bandwidth  economies  which  can  be  gained  if  an 
adaptive  approach  to  voice  services  on  this  ATM  network  by  transmitting  only  active 
connections  was  developed.  These  bandwidth  savings  would  then  be  released  for  use 
in  general  data  communications  providing  substantial  increases  in  communications 
capacity  for  automated  command  support  systems. 

Traffic  analysis  was  carried  out  to  determine  the  probability  density  function  of  the 
number  of  active  calls  in  the  busy  hour.  Three  alternative  designs  for  a  tactical  voice 
protocol  are  proposed  here  so  that  the  bandwidth  economy  can  be  quantified.  Given 
the  proposed  protocol,  the  bit  rate  required  to  carry  the  peak  load  and  the  average  bit 
rate  required  in  the  busy  hour  can  be  determined  and  compared  with  the  non- ATM 
approach.  The  results  of  this  analysis  show  that,  despite  the  imposition  of  additional 
protocol  overheads  from  the  ATM  and  other  related  protocols,  substantial  amounts  of 
bandwidth  would  be  released  if  the  voice  services  over  ATM  were  able  to  adapt  to  the 
number  of  channels  in  use.  Even  at  peak  usage  the  ATM  approach  expended  only  432 
kbps  i.e.  16  %  less  capacity  than  the  traditional  Parakeet  approach.  Over  the  entirety  of 
the  busy  hour  the  average  ATM  bit  rate  transmitted  was  231  kbps  ,  i.e.  a  further  saving 
of  46%. 

Capacity  released  by  the  voice  service  responding  to  call  and  speech  activity  is 
intended  to  be  used  by  Unspecified  Bit  Rate  (UBR)  traffic  between  automated 
command  support  systems.  A  brief  examination  is  made  that  indicates  that  data 
communications  protocols  should  be  able  to  access  the  capacity  released  by  call 
activity  detection  in  this  network.  Nevertheless  the  wider  issue  of  the  operation  of 
higher  layer  protocols  over  ATM  UBR  remains  the  subject  of  continuing  study. 

An  example  scenario  was  considered  where  the  link  between  the  two  busiest 
headquarters  was  1.024  Mbps.  It  was  assumed  that  256  kbps  was  set  aside  for  video 
conferencing  and  other  constant  bit  rate  services  (e.g.  a  superencrypted  link).  In  such  a 
scenario: 

if  the  traditional  Parakeet  approach  was  taken,  voice  services  would  use  512  kbps 
and  data  services  (apart  from  circuit  switched  data  connection  via  the  voice  services) 
would  have  access  to  a  fixed  rate  of  256  kbps; 

if  the  voice  services  and  all  data  were  combined  into  an  ATM  stream,  the  Constant 
Bit  Rate  (CBR)  services  would  consume  289  kbps  (i.e.  256  bkps  with  ATM  and  related 
overheads)  leaving  735  kbps  for  voice  and  data  services: 


if  voice  services  were  handled  as  a  CBR  ATM  service  they  would  consume  577 
kbps  leaving  a  fixed  rate  of  158  kbps  for  data  (i.e.  effective  rate  of  143  kbps  after 
eliminating  ATM  overheads) 

with  call  activity  processing,  voice  services  would  consume  during  the 
predicted  busy  hour  a  maximum  of  432  kbps  and  an  average  of  231  kbps.  This  would 
provide  a  data  service  with  303  kbps  (during  peaks)  and  504  kbps  on  average  (the 
effective  rates  after  eliminating  ATM  overheads  would  be  274  kbps  at  worst  and  447 
kbps  on  average). 

In  summary,  the  value  of  ATM  will  only  be  achieved  if  the  voice  services  in  Parakeet 
employ  a  dynamic  bandwidth  approach. 
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1.  Introduction 


The  Australian  Defence  Force  is  currently  procuring,  under  Project  Parakeet,  a  new 
digital  communications  network  for  use  by  forces  deployed  to  the  battlefield.  The 
system  employs  various  transmission  systems,  especially  satellite,  to  provide  voice  and 
data  services  between  headquarters.  It  is  based  on  a  military  standard  time  division 
multiplexed  (TDM)  system  known  as  EUROCOM  [1],  which  is  similar  in  concept  to  the 
civilian  integrated  services  digital  network  (ISDN).  Voice  systems  are  a  fundamental 
element  of  a  military  tactical  communications  system,  and  comprise  the  central 
element  of  the  Parakeet  network;  nevertheless,  increasing  data  communications 
demands  have  pushed  for  increased  data  capacity  in  the  network.  As  part  of  the  next 
phase  of  Parakeet,  a  limited  Asynchronous  Transfer  Mode  (ATM)  capability  will  be 
introduced  to  better  integrate  the  voice  and  data  uses  of  the  network. 

ATM  promises  to  be  the  underlying  protocol  of  the  next  generation  of 
telecommunications  systems.  It  exhibits  some  of  the  characteristics  of  circuit  switched 
systems  along  with  some  of  packet  switched  networks  with  the  aim  of  providing  a 
single  network  which  can  meet  the  needs  of  all  users.  The  fundamental  concept  of 
ATM  revolves  around  the  transfer  of  information  in  small,  fixed  length  packets  called 
cells.  The  small  size  means  that  the  time  taken  to  fill  the  cell  (cell  fill  latency)  is  kept 
relatively  low.  The  fixed  size  means  that  hardware  devices,  once  synchronised,  can 
delineate  and  switch  cells  at  very  high  speed.  Because  one  to  one  (or  one  to  many) 
circuits  are  established  prior  to  transmission,  as  with  circuit  switching,  the  header  does 
not  need  to  uniquely  identify  end  users;  instead  it  identifies  the  connection.  This 
means  that  the  cell  header  can  be  considerably  smaller  than  those  required  for  packet 
networks  so  that  while  the  cell  is  small,  the  header  overheads  do  not  become  too 
burdensome.  Like  packet  networks,  cells  from  multiple  sources  can  be  multiplexed  in  a 
flexible  fashion  allowing  users  to  obtain  bandwidth  on  demand  i.e.  dynamic 
bandwidth  allocation.  To  provide  the  link  between  user  applications  and  the  ATM  cell 
layer,  a  series  of  alternative  protocols  forming  the  ATM  Adaptation  Layer  (AAL)  have 
been  developed.  Different  AALs  provide  for  the  differing  characteristics  of  the  user 
application. 

While  there  are  definite  management  benefits  from  integrating  voice  services  into  the 
ATM  network,  the  unsophisticated  transmission  of  voice  over  ATM  will  incur 
bandwidth  penalties  via  the  addition  of  ATM  headers  and  other  AAL  overheads  to  a 
Constant  Bit  Rate  (CBR)  digital  voice  stream.  In  the  military  tactical  domain,  where 
bandwidth  is  at  a  premium,  this  overhead  makes  the  use  of  ATM  less  attractive 
compared  to  more  traditional  mechanisms  such  as  TDM.  Since  a  major  strength  of 
ATM  is  its  ability  to  carry  variable  bit  rate  (VBR)  traffic,  the  impact  of  the  overheads 
associated  with  the  ATM  protocol  might  be  reduced  or  eliminated  if  the  voice  traffic 
could  adopt  a  VBR  approach.  There  are  two  approaches: 

•  at  the  trunk  level  the  capacity  requirements  can  be  varied  to  reflect  the  number  of 
calls  being  connected  at  each  moment  (call  activity);  and 

•  at  the  call  level  the  capacity  requirement  of  each  channel  can  vary  according  to  the 
on-off  activity  in  the  conversation,  i.e.  speech  activity  (silence  detection). 

As  discussed  in  a  previous  report  [2],  silence  detection  is  the  much  harder  approach 
and  ought  not  be  attempted  in  the  first  fielding  of  ATM  in  Parakeet.  This  report 
expands  on  the  previous  work,  particularly  in  the  context  of  call  activity  processing. 
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2.  Aim 


The  aim  of  this  report  is  to  quantify  the  benefits  of  a  voice  service  over  Parakeet  ATM 
that  responds  to  call  activity. 


3.  A  Design  for  Voice  Telephony  over  Military 

Tactical  ATM 


There  are  significant  benefits  in  adopting  civil  standards  in  developing  a  tactical  voice 
ATM  system.  Nevertheless,  there  will  be  some  complicating  issues  arising  out  of  the 
specific  military  environment  and  these  are  considered  in  this  section.  Such  factors  as 
latency  and  bandwidth  efficiency  need  to  be  traded  off  in  developing  some  alternative 
approaches  and  these  are  analysed  further  in  this  report. 

3.1  The  Need  for  Adaptation  of  Standards 

In  designing  a  protocol  for  the  transmission  of  trunk  voice  channels  over  ATM  in  the 
military  tactical  domain,  there  are  a  number  of  factors  which  differentiate  this 
environment  from  civil  telephone  systems: 

•  Whereas  Pulse  Code  Modulation  (PCM  -  the  voice  coding  scheme  for  civilian 
systems)  is  an  octet-oriented  digital  standard  and  many  low  bit  rate  schemes 
produce  multi-octet  frames  (such  as  9.6  kbps  Code  Excited  Linear  Prediction  [CELP] 
which  produces  36  octet  frames).  Continuously  Variable  Slope  Delta  modulation 
(CVSD  -  used  in  Parakeet)  is  bit  oriented  and  the  codec  produces  a  stream  of  bits 
with  each  bit  indicating  a  change  to  the  waveform  amplitude. 

•  Because  the  codec  is  operating  at  a  low  bit  rate  (16  kbps  for  Parakeet)  protocol  frame 
sizes  which  would  be  acceptable  for  civil  systems  (in  terms  of  frame  fill  latency) 
may  be  unacceptable. 

•  While  call  activity  or  silence  suppression  mechanisms  may  not  be  implemented  in 
the  first  introduction  of  voice  over  tactical  ATM,  the  approach  taken  should  not 
preclude  its  introduction  as  a  future  option. 

•  Because  of  bandwidth  limitations,  there  should  be  minimal  overheads. 

3.2  Parakeet  Architecture 

Circuit  switching  technology  is  central  to  the  Parakeet  system.  All  services,  including 
X.25  packet  and  military  store  and  forward  messaging,  pass  through  the  circuit  switch. 
The  network  of  circuit  switches  are  interconnected  with  TDM  trunks.  While  the 
capacity  of  these  trunks  can  be  set  to  one  of  a  series  of  values  from  256  kbps  to 
2.048  Mbps,  trunks  typically  run  at  512  kbps  and  the  rate  cannot  be  changed  without 
disruption  to  ongoing  calls.  Meanwhile  the  user  is  provided  with  single  channels  with 
raw  data  capacity  of  16  kbps.  At  the  circuit  switch  it  is  possible  to  aggregate  up  to  a 
maximum  of  six  channels  to  produce  a  96  kbps  stream.  96  kbps  is  the  upper  limit  and 
cannot  be  changed  in  a  timely  fashion. 

The  routing  of  calls  from  one  user  to  another  is  via  a  flood  search  routing  algorithm 
rather  than  by  a  deterministic  mechanism.  Connection  requests  are  sent  from  the 
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originator's  circuit  switch  on  all  connected  links  and  are  subsequently  passed  on  by 
intermediate  circuit  switches  until  the  circuit  switch  supporting  the  intended  called 
party  responds.  The  path  of  the  response  signal  becomes  the  path  for  the  circuit.  This 
flood  search  routing  algorithm  will  allow  inter-connection  of  users  without  their 
knowledge  of  user  physical  locations. 

Overall,  while  the  Parakeet  system  is  providing  a  quantum  shift  in  capability 
compared  to  the  system  it  is  replacing,  it  does  not  provide  the  flexibility  that  modern 
data  communications  requires,  especially  in  a  bandwidth  poor  environment.  As  a 
consequence  the  decision  was  made  to  adopt  ATM  into  the  architecture. 

In  the  initial  introduction  of  ATM  into  Parakeet,  only  a  limited  number  of  nodes  will 
be  fitted  with  ATM.  At  an  ATM  fitted  node  the  circuit  switch  system  will  continue  to 
operate  so  that  it  can  connect  to  the  rest  of  the  circuit  switched  network.  Accordingly, 
the  circuit  switch  will  operate  alongside  the  ATM.  The  most  effective  composite 
architecture  is  to  use  the  ATM  network  to  carry  the  circuit  switch  trunks  and 
intelligently  multiplex  this  trunk  with  newer  applications. 

As  the  Parakeet  interswitch  signalling  is  proprietary,  it  will  be  difficult  to  develop  a 
solution  which  requires  interpretation  of  the  signalling.  Coupled  with  the  potential 
difficulties  in  coping  with  the  Parakeet  flood  search  routing  algorithm,  the  use  of  the 
ATM  system  as  a  virtual  transit  switch  is  not  considered  a  viable  option.  Since  the 
ATM  network  does  not  route  individual  connections,  calls  from  distant  points  in  the 
network  will  continue  to  traverse  a  number  of  circuit  switches  under  control  of  the 
flood  search  routing  algorithm.  At  each  entry  to  the  ATM  network,  the  transmission 
will  suffer  an  ATM  protocol  data  unit  fill  latency  and  this  will  accumulate  with 
multiple  links.  Accordingly,  approaches  which  minimise  fill  latency  will  be  preferable. 

While  the  interswitch  signalling  is  not  known,  the  trunk  multiplexing  waveform  is 
defined  in  EUROCOM  standards  so  individual  channels  could  be  demultiplexed  in  an 
interworking  unit  between  the  circuit  switch  and  the  ATM  switch.  If  the  indication 
pattern  transmitted  on  idle  channels  can  be  identified  then  these  channels  can  be 
suppressed  to  economise  on  bandwidth  use. 

The  simplest  mechanism  to  transport  the  voice  traffic  over  the  ATM  would  be  to  pass 
the  entire  512  kbps  trunk  over  an  unstructured  CBR  virtual  circuit  using  the 
appropriate  civil  standard  AAL  (AAL1).  This  is  easy  to  implement,  but  offers  no  scope 
for  any  bandwidth  economy  measures  to  overcome  the  unavoidable  ATM  overheads. 
With  a  small  increase  in  complexity,  an  approach  could  be  taken  where  each  voice 
circuit  (plus  the  signalling  channel)  passes  over  an  individual  AAL1  virtual  circuit. 
More  sophisticated  approaches  would  adopt  or  amend  the  multiplexed  options 
described  above. 

3.3  Proposed  Options 

The  overheads  associated  with  the  different  protocol  approaches  varies  as  a  function  of 
frame  size/frame  fill  latency  and  number  of  channels  to  be  moved.  Detailed 
comparisons  are  at  Appendix  A. 

The  EUROCOM  trunk  multiplex  structure  (for  larger  installations)  is  512  kbps.  This  is 
made  up  of  30  channels  of  16  kbps  voice  traffic,  one  channel  of  16  kbps  for  interswitch 
common  channel  signalling  and  one  16  kbps  synchronisation  channel.  This  512  kbps 
system  is  the  baseline  with  which  the  various  options  are  compared.  For  the 
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examinations  I  have  assumed  that  the  signalling  channel  will  remain  as  a  constant  bit 
rate  channel  since  the  nature  of  its  activity  is  not  known. 

Three  AAL  approaches  are  considered: 

•  Dynamic  Bandwidth  Allocation  using  Circuit  Emulation  Service.  In  this  protocol 
there  is  a  header  comprising  a  bit-map  identifying  which  TDM  slots  are  being 
carried  in  the  protocol  data  unit. 

•  AAL1.  This  option  examines  the  concept  of  each  voice  call  being  passed  on  a  unique 
AAL1  virtual  circuit.  The  overhead  of  this  protocol  is  simply  the  ATM  cell  header 
and  one  octet  AAL1  sequence  number.  Partially  filled  cells  are  considered. 

•  AAL  for  Composite  Users  (AAL-CU).  In  this  protocol  there  is  a  header  which 
provides  for  fields  such  as  call  identity,  user  to  user  flags  and  header  check  sums. 

Figure  1  provides  a  graphical  comparison  between  the  three  options  and  describes  the 
protocol  data  unit  (PDU)  structure  (particularly  the  non-standard  Dynamic  CES 
approach)  and  how  the  structure  is  segmented  into  ATM  cells  for  transmission  over 
the  ATM  path.  Each  protocol  has  a  header  which  results  in  overhead.  In  all  cases  larger 
voice  channel  frames  will  reduce  the  impact  of  this  overhead  but  at  the  price  of  longer 
frame  fill  latency. 

A  key  difference  between  the  three  AALs  is  the  method  used  to  identify  the  active 
TDM  channels  being  passed  via  the  ATM.  Since  the  TDM  trunk  must  be  re-created  at 
the  end  of  the  ATM  path  and  active  channels  will  be  distributed  throughout  the 
available  TDM  channels,  some  method  must  be  established  in  the  various  AALs  to 
map  transmitted  data  to  its  original  TDM  time  slot.  The  Dynamic  CES  approach 
maintains  the  TDM  time  slot  order,  and  uses  the  activity  bit  map  in  the  PDU  header  to 
identify  which  channels  appear  in  the  PDU.  The  AAL1  approach  uses  pre-arranged 
virtual  circuit  identifiers  to  distinguish  TDM  channels.  The  AAL-CU  has  a  channel 
identity  field  in  the  channel  frame  header  which  can  be  used. 

Data  from  ChnTT~l  Data  from  Chnl  2  |  Data  from  Chnl  3  | 

AAL1 


inurl 

III  Data  from  each  active  chnl  (n  bits  per  chnl  -  in  sequence  of  one  bit  per  chnl  in  turn)  j 

j|j||  next  data  | 

1  segment  1  f  I 

I  A: 

m 

HH! . I 

T . 

PH 

segment  4 

ctive  Channel  bit  map  one  octet 

sg5 

||  next  data  | 

[I]  AALl  header  (structure  point)  one  octet  per  8  cells 

Dynamic  CES 


Figure  1  -  Protocol  Data  Units 
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A  solution  employing  an  AAL1  virtual  circuit  per  voice  call  is  the  simplest  approach, 
but  has  unacceptable  overheads  unless  complete  cells  are  transmitted,  thus  incurring  a 
23.5  ms  cell  fill  latency.  This  is  borderline  for  acceptability,  especially  when  calls  need 
to  transit  several  Parakeet  switches,  nevertheless  it  will  be  retained  as  one  option. 

Lower  latencies  lead  to  less  efficient  transmission  in  all  protocol  approaches.  If  a  5  ms 
latency  is  selected,  then  an  approach  employing  dynamic  bandwidth  allocation  using  a 
modified  Dynamic  CES  is  the  best  solution  and  still  provides  quite  an  economic 
approach.  This  is  used  as  the  second  option  for  analysis.  Note  that  this  approach, 
whilst  based  on  the  civil  standard,  would  require  custom  development  by  the  ATM 
switch  vendor. 

To  use  the  civil  AAL-CU  standard,  intended  for  low  bandwidth  real-time  VBR 
services,  a  compromise  latency  must  be  selected.  AAL-CU  with  10  ms  latency  is  used 
as  the  third  option  in  the  analysis. 

Figure  2  shows  graphically  the  bandwidth  requirements  of  each  option  compared  with 
TDM  512  kbps. 


Figure  2  -  Parakeet  Trunk  Options 


An  examination  will  be  made  later  in  this  report  on  the  number  of  channels  that  is 
likely  to  be  required  for  an  operational  Parakeet  network.  Meanwhile,  if  a  full 
30  channel  group  is  to  be  moved,  ATM  and  protocol  overheads  will  clearly  mean  the 
ATM  options  will  require  more  bandwidth  than  the  TDM  solution.  The  bit  rate 
required  for  various  options  is  given  in  Table  1.  (Note  that  the  AAL1  option  with  one 
TDM  channel  per  virtual  circuit  should  not  need  to  carry  the  synchronisation  channel.) 
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Table  1-30  Channel  Bit  Rate  Requirements 


Bit  Rate  Required 

Overhead  Compared 
to  512  kbps 


AAL1  for 

Dynamic 

AAL1  (one  VC 

AAL-CU 

Entire  512 

CES 

per  TDM 

kbps  Trunk 

channel) 

577  kbps 

556  kbps 

559  kbps 

643  kbps 

13% 

9% 

9% 

26% 

3.4  Summary 

This  section  has  considered  the  special  factors  arising  from  the  military  tactical 
environment,  in  particular  recognising  the  Parakeet  architecture.  In  trading  off  the  two 
requirements  of  latency  and  bandwidth  economy,  it  has  proposed  three  protocols  for 
the  transmission  of  voice  trunks  in  Parakeet.  The  Dynamic  CES  approach  is  a 
modification  of  the  civil  equivalent,  but  the  other  two  are  civil  standards.  All  use  more 
bandwidth  than  TDM  for  numbers  of  channels  approaching  the  30  traffic  channels 
carried  by  the  512  kbps  TDM  trunk,  but  support  VBR  applications  and  use  less 
bandwidth  with  fewer  channels  being  transmitted.  Later  sections  will  determine  the 
number  of  channels  that  would  be  expected  to  be  moved  simultaneously. 


4.  Capacity  Management  in  Parakeet  ATM 

A  key  activity  in  managing  the  Parakeet  ATM  network,  will  be  the  allocation  of 
capacity  on  the  links  between  nodes.  Central  to  such  management  in  a  large  scale  civil 
network  is  the  concept  of  statistical  multiplexing.  This  concept  is  explained  in  this 
section  and  subsequent  sections  will  consider  whether  it  will  be  significant  in  the 
Parakeet  network.  A  concept  is  developed  in  this  section  for  bandwidth  management 
which  provides  a  framework  on  which  to  base  bandwidth  savings  estimates. 

It  is  envisaged  that  there  will  be  three  major  classes  of  users  between  which  capacity 
must  be  shared  for  a  particular  link: 

•  Voice  Trunk.  This  is  a  real-time  service.  While  this  traffic  might  be  passed  as  a 
single  virtual  circuit  or  multiple  virtual  circuits,  the  composite  should  managed  as  a 
single  entity. 

•  Other  Real-time  Services.  These  are  services  such  as  room  based  video 
conferencing  and  each  should  be  managed  individually. 

•  Non-Real-time  Services.  Typically  these  are  tolerant  of  delay  and  delay  variation, 
for  instance  computer  interconnection  for  mail,  file  transfer  etc. 


4.1  Average  Rate  Management  versus  Peak  Rate  Management 

In  a  large  network,  for  which  ATM  was  originally  designed,  a  capacity  management 
approach  to  VBR  services  was  proposed  based  on  statistical  multiplexing.  It  is  argued 
that  if  a  large  number  of  VBR  sources  are  multiplexed  the  short  term  capacity  peaks  of 
each  service  would  be  decorrelated.  Thus  the  total  bandwidth  demand  would  be  less 
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variable  than  individual  sources  and  tend  to  the  sum  of  each  source's  average  capacity 
requirement.  Bandwidth  could  then  be  allocated  to  the  composite  based  on  this  sum. 

This  approach  is  not  recommended  for  Parakeet  as  statistical  multiplexing  becomes 
most  effective  with  large  numbers  of  sources  and  Parakeet  will  have  few  such  VBR 
sources.  Nevertheless,  the  statistical  multiplexing  effect  will  be  considered  in  this 
study  in  respect  of  the  combination  of  multiple  VBR  voice  sources  within  the  voice 
trunk. 

Instead,  an  approach  of  peak  rate  management  of  real-time  services  is  suggested  for 
Parakeet.  To  meet  quality  of  service  requirements  of  real-time  services,  sufficient 
capacity  must  be  allocated  to  meet  the  peak  requirements.  This  ensures  that  cell  loss 
and  cell  delay  variation  are  minimised.  Once  all  real-time  services  have  been  allocated 
their  peak  requirements  the  remaining  capacity  is  in  effect  allocated  for  non-real-time 
services.  In  addition,  capacity  unused  by  real-time  services  operating  at  less  than  peak 
requirement,  is  available  to  non-real-time  services. 


4.2  An  Approach  at  Looking  at  Bandwidth  Savings 

Figure  3  shows  how  capacity  might  be  allocated  between  real-time  services  and  non- 
real-time  services.  This  also  provides  a  model  upon  which  bandwidth  savings  might 
be  considered. 

The  peak  requirement  for  voice  services  will  be  driven  by  call  characteristics. 
Depending  on  the  statistics  of  arrival  rate  and  call  holding  time,  the  number  of 
channels  occupied  (i.e.  the  number  of  simultaneous  calls)  will  vary  in  accordance  with 
a  probability  density  function.  From  this  function,  the  maximum  number  of  calls  can 
be  determined. 

Note  that  in  calculating  the  capacity  requirements  of  the  system  to  forecast  bandwidth 
savings,  I  have  chosen  not  to  dimension  the  voice  service  bandwidth  to  meet  the 
absolute  maximum  requirement.  Instead  I  have  considered  the  99.9%  cumulative 
probability  as  the  peak  requirement.  In  effect  this  means  that  for  0.1%  of  time  in  the 
busy  hour,  the  capacity  considered  in  this  analysis  to  be  allocated  to  voice  services 
would  be  insufficient  and  some  calls  may  lose  a  short  period  of  their  transmission.  In 
the  worst  instance,  a  call  request  at  this  moment  may  be  disrupted.  The  0.1%  is 
consistent  with,  and  will  more  than  meet,  the  Parakeet  performance  specification 
which  demands  a  grade  of  service  for  high  priority  voice  users  of  0.001  (i.e.  0.1%). 

The  difference  between  the  peak  bandwidth  requirement  and  the  bandwidth  value 
that  had  originally  been  assigned  to  voice  services  (up  to  the  maximum  link  capacity) 
is  then  a  measure  of  the  savings  that  can  be  allocated  to  non-real-time  services  with  a 
reasonable  degree  of  assurance  that  it  will  be  available  at  all  times.  The  difference 
between  the  peak  bandwidth  requirement  and  the  actual  bandwidth  requirement  at 
any  moment  in  time  will  also  be  released  to  non-real-time  services.  However  the 
amount  released  will  vary  in  time  driven  by  the  changing  call  activity.  Over  a  period, 
the  amount  released  will  be  determined  by  the  average  bandwidth  requirement  of  the 
voice  service. 
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requirement 

Figure  3  -  Capacity  Allocation 


Capacity  freed 
for  non-real  time 
varying  with  time 


Average 

real-time 

requirement 


If  one  calculates  the  average  capacity  required  for  the  voice  services,  one  can 
determine  the  average  capacity  that  would  be  unused  and  hence  available  for  use  to 
non-real-time  services  on  an  opportunity  basis.  This  calculation  is  done  by  weighting 
the  capacity  requirements  for  each  value  of  voice  channels  in  use  with  the  probability 
distribution  of  the  number  of  channels  being  used. 


4.3  Summary 

It  is  argued  here  that  statistical  multiplexing,  effective  with  large  numbers,  is  not 
appropriate  to  Parakeet.  Instead  an  approach  using  peak  rate  allocation  is  proposed. 
Capacity  exceeding  the  peak  rates  requirements  of  real-time  services  can  be  assigned 
to  non-real-time.  The  average  requirement  of  the  real-time  services  will  reveal  capacity 
which  can  released  over  a  period  to  non-real-time  services.  The  concept  of  peak  usage 
and  average  usage  will  provide  a  framework  for  the  description  of  bandwidth  savings. 


5.  Bandwidth  Savings  from  Parakeet  Voice  Call 

Activity 

This  section  seeks  to  identify  the  bandwidth  savings  achievable  through  responding  to 
connection  activity.  The  section  first  carries  out  traffic  analysis  to  determine  the  call 
activity  characteristics  of  the  busiest  trunk  in  the  Parakeet  network.  It  then  considers 
the  bandwidth  required  to  meet  this  traffic  profile. 
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5.1  Determination  of  Voice  Traffic  Load 

5.1.1  Method 

In  order  to  determine  the  bandwidth  benefits  from  an  ATM  protocol  responsive  to  call 
activity,  the  Parakeet  traffic  characteristics  are  required.  Since  Parakeet  is  producing  a 
totally  new  capability  for  the  Australian  Defence  Force,  the  usage  of  the  network  is  not 
known  with  any  great  certainty.  Traffic  statistics  were  provided  as  part  of  the  current 
Parakeet  contract  and  these  figures  are  taken  as  indicative  of  the  operational  network 
for  the  purpose  of  this  study. 

The  Parakeet  network  topology  is  flexible  and  indeed  dynamic,  and  would  be 
responsive  to  the  military  operational  situation  at  the  time.  For  the  purposes  of  the 
statistical  analysis,  traffic  figures  are  provided  for  an  indicative  reference  network 
layout  shown  in  Appendix  B.  Since  this  network  is  equipped  only  with  traditional 
circuit  switches,  and  Parakeet  is  initially  only  equipping  about  six  nodes  with  ATM, 
the  author  conducted  discussions  with  the  Parakeet  project  office  to  select  the  most 
appropriate  nodes  to  be  modelled  with  ATM. 

The  traffic  load  statistics  from  the  Parakeet  specification  were  processed  to  determine 
the  busy  hour  call  arrival  rate  for  the  busiest  trunk  link.  This  was  then  used  in  a 
conventional  statistical  model  to  determine  the  probability  density  function  for  the 
number  of  active  channels  in  the  busy  hour. 


5.1.2  Results 

The  detailed  results  were  developed  in  two  spreadsheets  which  are  replicated  in 
Appendix  B.  One  spreadsheet  analyses  the  call  activity  to  determine  busy  hour  call 
arrival  rate  and  the  second  carries  out  statistical  analysis  (multifacility  queuing 
system)  to  determine  channel  activity.  The  Parakeet  reference  network  used  for  this 
analysis  is  shown  in  Figure  4.  Results  of  each  analysis  are  given  here  in  Table  2. 


Figure  4  -  Parakeet  Reference  Network 
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Table  2  -  ATM  Trunk  Loading 


ATM  Trunk 
Name 

Parakeet  Nodes 
Interconnected 

Number  of  Calls 
initiated  in  the 
Busy  Hour 

A1 

L6/S6 

69.375 

A2 

S6/L8 

233.125 

A3 

L6/L10 

130.625 

A4 

L8/L10 

154.000 

A5 

L9/L10 

157.750 

A6 

LI  0/L1 1 

130.125 

A7 

L10/L13 

85.000 

A8 

L8/L9 

224.375 

A9 

L9/L11 

130.625 

Appendix  C  provides  a  table  showing  the  probability  density  function  of  the  call 
activity,  this  is  shown  graphically  in  Figure  5.  Note  the  low  probability  of  exceeding 
23  active  channels  (99.9%  i.e.  less  than  4  seconds  in  one  hour). 


P(N) 


Figure  5  -  Probability  Density  Function  for  Busy  Hour  Call  Activity  on  the  Busiest 
Trunk 

5.2  Bandwidth  Savings  from  Dynamic  Bandwidth  Use  in  Response  to 
Call  Activity 

Two  calculations  have  been  carried  out  (detailed  table  of  results  at  Appendix  C): 

•  Assuming  23  channels  in  use.  This  is  equivalent  to  the  worst  case,  i.e.  sufficient 
channels  to  cater  for  99.9%  situation  on  the  busiest  trunk  in  the  busy  hour.  The  bit 
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rate  requirements  from  this  situation  should  be  reserved  for  voice  use  in  a  peak  rate 
management  approach.  Any  excess  transmission  capacity  above  this  peak  rate  can 
reasonably  be  assigned  to  high  priority  non-voice  uses. 

•  Over  the  entire  probability  range  of  Channels  in  Use.  This  determines  the 
weighted  average  bit  rate  by  considering  the  bit  rate  required  for  each  channel 
usage  situation  and  weighting  that  figure  by  the  probability  of  that  number  of 
channels  being  required.  The  resultant  bandwidth  requirement  is  then  assessed 
against: 

•  The  ATM  Trunking  Requirements  for  23  Channels.  This  provides  a 
measure  of  the  bandwidth  that  would  be  released  in  an  ATM  system  to  low 
priority  uses,  and 

•  512  kbps.  This  provides  a  measure  of  the  overall  savings  compared  with 
TDM  that  would  be  achieved  through  the  adoption  of  that  ATM  trunking 
approach). 

Table  4  -  Bandwidth  Savings  from  Call  Activity 

Bandwidth  Savings  Compared  to  512  kbps  when  23  Calls  are  Active 


Dyn 

CES 

AAL1 

AAL-CU 

B/W  Reqt 
for  23 

Chan 

432.2 

kbps 

433.0 

kbps 

498.0 

kbps 

Saving 

16% 

15% 

3% 

Bandwidth  Savings  Through  Call  Activity  Detection 


Dyn 

CES 

AAL1 

AAL-CU 

Weighted 
Average 
B/W  Reqt 

231.3 

kbps 

228.3 

kbps 

262.6 

kbps 

%age  saving  on  23  channel  requirement  %age  saving  on  512  kbps 


Dyn 

CES 

AAL1 

AAL-CU 

46% 

47% 

47% 

Dyn 

CES 

AAL1 

AAL-CU 

55% 

55% 

49% 

5.3  Summary 

These  figures  indicate  significant  savings,  particularly  in  the  case  of  Dynamic  CES  and 
AAL1.  In  these  cases  the  bandwidth  requirement  for  the  predicted  busy  hour,  busiest 
link  channel  occupancy  of  23  channels  is  clearly  less  than  the  30  channel  TDM 
requirements.  By  responding  to  call  activity,  even  this  peak  requirement  has  more  than 
overcome  the  ATM  and  AAL  overheads  and  provides  savings.  Furthermore, 
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substantial  savings  are  available  over  the  course  of  the  busy  hour  to  the  tune  of  about 
half  of  the  capacity  that  would  otherwise  have  been  reserved  exclusively  for  voice 
services. 


6.  Ability  to  Make  Use  of  Released  Capacity 

In  the  concept  of  bandwidth  management  proposed  in  this  report,  capacity  for  the 
voice  and  other  real-time  services  is  reserved  based  on  a  peak  rate.  This  will  ensure 
that  cell  loss  and  cell  delay  variation  are  minimised  for  real-time  services.  Capacity 
released  by  the  voice  service  responding  to  call  activity  is  intended  to  be  used  by 
Unspecified  Bit  Rate  (UBR)  traffic.  It  is  not  immediately  apparent  whether  higher  layer 
data  communications  protocols  have  the  ability  to  respond  adequately  to  make  use  of 
the  changing  capacity.  Variations  in  channel  usage  which  derive  the  variations  in 
spare  capacity  will  cause  variations  in  UBR  cell  transmissions.  Higher  layer  data 
communications  protocols  will  perceive  these  variations  as  variations  in  the  round  trip 
time  (RTT)  of  acknowledgments  of  transmitted  packets.  When  capacity  released  to 
UBR  is  high  then  cells  are  released  quickly  with  a  consequent  reduction  in  the  time 
taken  for  packets  to  reach  their  destination  and  acknowledgments  to  be  returned. 

In  examining  the  ability  of  higher  layer  protocols  to  take  advantage  of  the  capacity 
released  by  VBR  voice  services  two  questions  must  then  be  asked:  what  is  the  nature  of 
the  variation  in  capacity  -  as  perceived  by  the  higher  layer  protocol;  and  how  will  this 
impact  on  the  higher  layer  flow  control  strategy.  For  the  purposes  of  this  study,  the 
higher  layer  protocol  considered  is  the  internet  Transmission  Control  Protocol  (TCP). 


6.1  Data  Capacity  Available 

For  the  purposes  of  this  analysis,  a  small  simulation  was  developed  depicting  the  busy 
hour  on  the  busiest  trunk.  Call  activity  was  generated  in  the  model  using  the  traffic 
statistics  determined  earlier.  A  record  was  then  made  of  the  number  of  active  channels 
in  each  time  slot  (each  of  1  second)  of  the  simulation.  An  extract  of  that  record  is 
shown  in  Figure  6  to  show  the  time  scales  of  the  capacity  changes.  It  was  chosen  for 
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Figure  6  -  Time  Series  Showing  Number  of  Channels  Active 
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display  because  of  the  large  variation  in  channel  usage  and  to  see  the  impact  of  this  on 
TCP. 

As  the  number  of  active  channels  varies,  the  bandwidth  consumed  by  the  voice 
services  changes  (with  the  precise  demand  dependent  on  the  AAL  employed).  To 
consider  how  this  variation  impacts  on  the  capacity  available  to  data  communications 
one  must  know  the  total  capacity  available  for  voice  and  data.  Parakeet  satellite 
terminals  are  limited  to  a  2.048  Mbps  throughput,  but  typically  this  capacity  would  be 
shared  between  two  links.  For  the  purposes  of  this  analysis,  the  1.024  Mbps  for  a  link  is 
assumed  to  allocated  with  256  kbps  set  aside  for  video  conferencing  and  other  CBR 
services  (consuming  almost  289  kbps  with  ATM/AAL1  overheads)  with  the  remaining 
735  kbps  shared  between  voice  services  and  data. 

The  capacity  available  to  data  communications  can  now  be  examined.  This  was 
calculated  for  the  simulation  using  the  Dynamic  CES  option.  A  short  portion  of  the 
results  showing  the  corresponding  period  as  Figure  6  is  shown  in  Figure  7.  Also  shown 
is  the  capacity  that  would  have  been  available  to  data  if  the  voice  service  did  not 
respond  to  call  varying  activity  thus  consuming  577  kbps  (512  kbps  with  ATM/AAL1 
overheads). 


Figure  7  -  Time  Series  Showing  Data  Capacity  Available 
6.2  Impact  on  TCP 

TCP  is  a  fundamental  protocol  within  the  Internet  and  intrinsic  to  the  protocol  is  a 
mechanism  to  cope  with  variations  in  RTT  caused  by  variations  in  congestion.  The 
throughput  of  TCP  is  a  complex  interaction  between  the  TCP  acknowledgment 
window  (the  number  of  transmitted  packets  awaiting  acknowledgment)  and 
transmission  timeout  interval.  Of  particular  concern  is  the  transmission  timeout  as,  if  a 
packet  is  not  acknowledged  before  timing  out,  TCP  will  assume  congestion,  reduce  its 
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transmission  rate  and  retransmit  all  packets  in  the  window.  RTT  variation  can  impact 
on  throughput  as  RTT  is  used  by  TCP  to  set  timeout  intervals  for  waiting  for 
acknowledgments.  Short  term  variations  in  RTT  are  handled  through  two  aspects  of 
typical  TCP  implementations  as  conceived  by  Van  Jacobson  and  described  in 
Tanenbaum  [3]  Chapter  6: 

•  The  timeout  is  based  on  an  exponentially  smoothed  figure  for  estimated  RTT.  The 
estimated  RTT  is  revised  with  the  arrival  of  most  packets  and  is  the  weighted 
average  of  the  previous  estimate  and  the  measured  RTT  for  that  packet.  The 
previous  estimate  has  the  greater  weight,  typically  7/8. 

•  The  timeout  is  typically  set  to  the  estimated  RTT  plus  (typically)  four  times  the 
mean  deviation  in  RTT. 

In  an  ATM  system,  non-real-time  services  attract  a  lower  priority  in  the  scheduling  of 
cells  onto  the  transmission  link.  To  reduce  the  possibility  of  cell  loss,  such  services  are 
handled  through  relatively  long  buffers.  In  the  case  of  the  DSTO  research  ATM 
network,  these  buffers  are  of  the  order  of  1000  cells  (about  380,000  bits  of  user  data).  As 
link  capacity  available  to  the  non-real-time  services  waxes  and  wanes,  the  length  of 
queued  data  in  the  buffer  will  consequently  and  inversely  wane  and  wax.  Clearly  as 
the  queue  enlarges,  the  transit  time  for  the  TCP  packet  to  traverse  the  network  will 
increase  and  the  time  taken  for  acknowledgments  to  be  received  at  the  sending  process 
will  increase.  Increasing  delay  in  receiving  acknowledgments  has  a  secondary  impact 
by  slowing  traffic  offered  by  TCP  as  new  traffic  cannot  be  offered  until  outstanding 
packets  are  acknowledged. 

The  most  catastrophic  thing  that  can  happen  to  a  TCP  stream  is  for  a  packet 
acknowledgment  to  timeout.  This  can  occur  either  through  the  RTT  exceeding  the 
timeout  limit  or  if  the  packet  is  dropped,  either  in  whole  by  an  IP  router  or  in  part  by 
the  overflow  of  an  ATM  link  buffer.  If  the  TCP  acknowledgment  times  out,  TCP 
drastically  reduces  the  amount  it  is  prepared  to  send  in  each  burst.  The  rate  at  which 
this  amount  is  allowed  to  increase  is  initially  quite  fast,  but  once  a  threshold  is  reached 
(determined  by  what  had  been  happening  on  the  network  in  the  immediate  past)  the 
rate  of  increase  becomes  quite  slow. 

The  impact  of  the  varying  data  capacity  was  examined  in  the  simulation.  A  simple 
model  was  developed  with  a  single  TCP  source  and  terrestrial  transmission  path.  This 
was  chosen  so  that  the  impact  of  the  varying  data  capacity  was  not  hidden  by  other 
factors  such  as  interaction  between  multiple  TCP  processes  or  the  impact  of  satellite 
delay  on  TCP.  (These  are  covered  in  the  general  literature  with  some  interesting 
analysis  in  Goyal  [4]).  An  examination  of  the  performance  of  this  simple  model  shows: 

•  The  ATM  buffers  are  quite  large  compared  to  the  variation  in  available  capacity 
(buffers  are  of  the  order  of  380  kbits  while  the  standard  deviation  of  the  data 
capacity  figure  is  less  than  64  kbps).  While  such  buffers  are  insufficient  to  cope  if 
TCP  was  transmitting  at  fixed  rate  equal  to  the  average  available  capacity,  they 
have  shown  to  be  sufficient  to  absorb  the  mismatches  between  the  adaptive  TCP 
rate  and  the  available  bandwidth.  ATM  buffers  do  not  suffer  overflow  in  the  model. 

•  In  this  model,  when  the  TCP  stream  starts  it  has  a  poor  estimate  of  RTT. 
Consequently  the  initial  transmissions  suffer  a  number  of  timeout  failures.  Very 
soon  the  estimate,  and  the  RTT  deviation,  become  a  more  accurate  representation  of 
the  network  performance  and  timeouts  no  longer  occur. 
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•  After  the  timeouts  are  resolved,  the  transmission  burst  size  slowly  increases  until 
the  maximum  is  gained,  and  remains  at  that  size  for  the  remainder  of  the 
simulation.  This  is  the  logical  outcome  from  the  situation  where  there  are  no  further 
timeouts  caused  by  excessive  acknowledgment  delay  or  loss  of  transmission 
through  buffer  overflow. 

•  Buffer  queue  length  and  available  bit  rate  then  determine  the  RTT  and  hence  time 
before  TCP  can  send  more  traffic.  This  effectively  modulates  the  transmission  of 
TCP  packets  into  the  network.  Figure  8  depicts  the  TCP  goodput  (i.e.  the  size  of 
successful  TCP  transmissions  commenced  in  each  time  slot)  for  a  segment  of  the 
simulation. 

•  Average  available  bit  rate  for  this  simulation  is  581  kbps.  The  TCP  stream  averages 
480  kbps. 


TCP  Goodput  vs  Bandwidth  Available 
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Figure  8  -  Time  Series  Showing  TCP  Goodput 


The  mechanisms  conceived  by  Van  Jacobsen  would  therefore  appear  to  be  sufficient  to 
cope  with  the  variability  in  capacity  for  the  system  considered  in  this  report. 
Nevertheless  the  wider  issue  of  TCP  over  ATM  UBR,  especially  over  satellite  and  over 
congested  networks,  remains  an  open  question  and  a  subject  of  continuing  study  see 
Goyal  [4]. 


6.3  Summary 

This  section  has  considered  whether  the  capacity  released  by  call  activity  detection  can 
be  effectively  used  by  higher  layer  data  protocols,  specifically  TCP.  With  the  in-built 
mechanisms  to  cope  with  short  term  variability  in  network  capacity  available  in  TCP, 
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there  is  reason  to  have  some  confidence  in  the  ability  of  TCP  to  use  much  of  the 
released  capacity. 


7.  Conclusions 


The  introduction  of  ATM  into  traditional  TDM  communication  systems  provides 
significant  benefits  in  the  areas  of  responsive  network  management  and  the 
integration  of  multiple  communication  applications.  The  penalty  which  comes  with 
this  benefit  is  the  additional  overheads  intrinsic  to  ATM  and  associated  protocols.  This 
report  seeks  to  quantify  capacity  economies  which  can  be  achieved  through  the 
development  of  a  VBR  approach  to  the  passage  of  voice  services  through  the  ATM 
network  transmitting  only  those  channels  between  circuit  switches  which  have  active 
connections. 

Parakeet  has  been  designed  for  use  in  a  tactical  (mobile)  military  environment.  It 
employs  military  standard  protocols  which,  while  similar  in  function  to  civil 
standards,  are  quite  different  in  implementation.  Accordingly,  in  order  to  quantify  the 
bandwidth  economy  measures,  three  alternative  designs  have  been  proposed  as  a 
tactical  voice  protocol.  These  are  either  direct  civil  implementations  or  based  on  civil 
standard  approaches. 

To  compare  the  bandwidth  requirements  of  a  VBR  approach  with  that  using  a  fixed 
allocation  two  measures  of  bandwidth  savings  are  defined: 

•  The  first  determines  the  peak  bandwidth  requirement  of  the  VBR  approach  and 
compares  this  to  the  fixed  allocation.  This  saving  ought  never  be  intruded  upon 
and  can  be  reasonably  allocated  to  other  services. 

•  The  second  calculates  the  average  bandwidth  requirement  of  the  VBR  approach 
and  compares  this  to  the  peak  allocation.  This  capacity  waxes  and  wanes  over  time 
and  hence  can  only  be  allocated  to  non-real-time  uses. 

Traffic  statistics  from  the  Project  Parakeet  contract  were  analysed  to  determine  busy 
hour  traffic  arrival  rate  and  call  holding  times  for  the  busiest  trunk.  Queuing  theory 
(multifacility  queuing  system)  analysis  was  carried  out  and  this  showed  that  peak 
channel  occupancy  (99.9%  level)  was  only  23  out  of  the  30  channels  available  on  that 
link.  This  provides  considerable  opportunity  for  savings.  With  the  preferred  voice 
trunking  options: 

•  capacity  required  for  peak  activity  is  around  15%  lower  than  the  traditional  TDM 
system 

•  average  capacity  in  the  busy  hour  is  around  46%  lower  than  the  requirement  for 
the  peak  load. 

Capacity  released  by  the  voice  service  responding  to  call  activity  is  intended  to  be  used 
by  Unspecified  Bit  Rate  (UBR)  traffic.  Variations  in  channel  usage  which  derive  the 
variations  in  spare  capacity  will  cause  variations  in  UBR  throughput.  The  higher  layer 
data  communications  protocols  will  perceive  these  variations  through  variations  in  the 
round  trip  time  (RTT)  of  acknowledgments  of  transmitted  packets.  It  is  not 
immediately  apparent  whether  higher  layer  data  communications  protocols 
(particularly  TCP)  have  the  ability  to  respond  adequately  to  such  changing  capacity. 
An  examination  of  the  simulation  developed  for  this  report  suggests  that  the  capacity 
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is  useable  given  the  algorithms  inbuilt  with  TCP  to  cope  with  variations  in  RTT. 
Moreover,  while  there  is  still  work  being  done  in  assessing  the  ability  to  use  all  of  the 
capacity  released  by  these  techniques,  it  is  important  not  to  lose  sight  of  the  significant 
capacity  released  when  considering  the  peak  requirements  alone. 
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9.  Abbreviations 


AAL 

ATM 

CBR 

CVSD 

ISDN 

ITU 

RTT 

TCP 

UBR 

VBR 


ATM  adaptation  layer 
Asynchronous  Transfer  Mode 
constant  bit  rate 

continuously  variable  slope  delta  modulation 
integrated  services  digital  network 
International  Telecommunications  Union 
round  trip  time 
transmission  control  protocol 
unspecified  bit  rate 

variable  bit  rate  -rt  for  real-time  and  nrt  for  non-real-time  applications 
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Appendix  A:  Parakeet  Voice  Trunk  Options 

1.1  Introduction 

Figure  A-l  shows  diagrammatically  the  three  options  developed  for  this  study. 

Data  from  Chnl  1~]  Data  from  Chni  2]  Data  from  Chnl  3] 

AAL1 


nnr 

||j  Data  from  each  active  chnl  (n  bits  per  chnl  -  in  sequence  of  one  bit  per  chnl  in  ti 

jrn) 

II  segment  1  j 

||  j  next  data  | 

B  A 

H§|8^  segment  2  | 

HHi _ 

mu 

segment  4 

ctive  Channel  bit  map  one  octet  [llfllfi 

sg5 

j||  next  data  | 

||  AALl  header  (structure  point)  one  octet  per  8  cells 


Dynamic  CES 


Figure  A-l:  Three  Trunk  Options  for  Parakeet 

A  key  difference  between  the  three  AALs  is  the  method  used  to  identify  the  active 
TDM  channels  being  passed  via  the  ATM.  Since  the  TDM  trunk  must  be  re-created  at 
the  end  of  the  ATM  path  and  active  channels  will  be  distributed  throughout  the 
available  channels,  some  method  must  be  established  in  the  various  AALs  to  map 
transmitted  data  to  its  original  TDM  time  slot. 


1.1.1  AALl 

This  option  passes  each  voice  call  plus  the  signalling  channel  on  a  unique  AALl 
virtual  circuit.  Prearranged  virtual  channel  identifiers  can  be  assigned  to  map  channels 
on  the  TDM  trunk  to  ATM  virtual  circuits.  The  ATM/ AAL  overhead  of  this  protocol  is 
simply  the  ATM  cell  header  and  one  octet  AALl  sequence  number.  Since  an  integral 
number  of  cells  must  be  transmitted,  overheads  are  minimised  for  a  frame  size 
equivalent  to  the  AALl  payload  (47  octets  =  376  bits)  or  an  integral  multiple  of 
payloads  (this  would  eliminate  wasteful  bit  padding).  The  number  of  53  octets  cells  per 
PDU  is  thus  given  by  frame  size/376  rounded  up  to  the  next  integer. 

The  rate  at  which  PDUs  are  produced  by  each  channel  is  the  individual  channel  rate 
divided  by  the  frame  size.  Since  the  voice  channel  bit  rate  is  16  kbps,  the  PDU 
production  rate  is  16/frame  size  kPDU  per  second  per  channel.  The  PDU  fill  latency 
encountered  by  each  channel  is  the  inverse  of  the  figure. 
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The  overall  bit  rate  of  this  AAL  is  thus  given  by  the  following: 

bits  per  cell  *  cells  per  PDU  *  PDU  production  rate  per  channel  *  number  of  channels 

(53*8)  *  (frame  size/376  rounded  up)  *  (16/frame  size)  *  number  of  channels  kbps 

(Note  the  number  of  channels  is  the  number  of  traffic  channels  plus  one  channel  for 

signalling.) 

1.1.2  Dynamic  CES 

This  option  passes  the  entire  trunk  (all  voice  calls  plus  the  signalling  channel)  on  a 
single  AAL1  virtual  circuit.  The  PDU  has  a  four  octet  header  representing  a  bit-map  to 
identify  which  TDM  slots  are  being  carried  in  the  body  of  the  protocol  data  unit.  The 
ATM/ AAL  overhead  of  this  protocol  is  the  ATM  cell  header,  one  octet  AAL1  sequence 
number  per  cell,  one  octet  AAL1  structure  pointer  (to  point  to  the  start  of  a  PDU)  per 
eight  cells  and  the  bit  map  octets  per  PDU.  The  structure  pointer  is  required  as  the 
PDUs  are  not  synchronised  to  always  start  at  the  beginning  of  a  cell  -  thus  there  is  no 
need  for  padding. 

This  AAL  is  a  derivative  of  the  civil  equivalent  [5].  Whereas  the  civil  system  transmits 
octets  of  voice  channel  data  (because  PCM  is  octet  based),  the  proposed  tactical  design 
transmits  individual  channel  data  as  bits  (as  done  in  the  EUROCOM  TDM  frame  [6]). 
A  frame  size  (n)  for  each  channel  is  defined  as  the  number  of  bits  being  carried  in  the 
PDU  for  a  channel.  The  Dynamic  CES  structure  wil]  then  be  four  octets  of  header  plus 
n  bits  per  channel  (i.e.  the  number  of  active  channels  plus  one  channel  of  signalling). 
The  data  portion  of  the  structure  is  one  bit  per  channel  in  sequence  through  the 
channels  being  carried.  The  AAL1  structure  pointer  must  point  to  the  bit  map  and  this 
must  appear  on  an  octet  boundary;  this  is  most  easily  arranged  by  having  each  channel 
frame  to  be  an  even  number  of  octets. 

Because  of  the  structure  pointer,  the  number  of  octets  per  cell  is  on  average  47.875.  The 
average  number  of  53  octet  cells  produced  by  a  Dynamic  CES  PDU  is: 

(4  +  (channel  frame  size  in  octets)  *  (number  of  channels)  )/47.875 

The  rate  at  which  PDUs  are  produced  is  the  individual  channel  rate  divided  by  the 
frame  size  (in  bits)  per  channel.  Since  the  voice  channel  bit  rate  is  16  kbps,  the  PDU 
production  rate  is  16/frame  size  (in  bits)  kPDU  per  second.  The  PDU  fill  latency 
encountered  by  each  channel  is  the  inverse  of  the  figure. 

The  overall  bit  rate  of  this  AAL  is  thus  given  by  the  following: 

bits  per  cell  *  cells  per  PDU  *  PDU  production  rate  per  channel  *  number  of  channels 
(53*8)  *  ((4  +  (frame  size  in  octets)  *  (number  of  channels)  )/47.875)  *  (16/frame  size  in 
bits)  kbps 

(Note  the  number  of  channels  is  the  number  of  traffic  channels  plus  one  channel  for 
signalling.) 

1.1.3  AAL-CU 

The  option  uses  the  civil  standard  [7]  and  passes  the  entire  trunk  (all  voice  calls  plus 
the  signalling  channel)  on  a  single  ATM  virtual  circuit.  Associated  with  each  channel 
frame  is  a  three  octet  header  which  carries,  amongst  others,  a  channel  identity  field 
which  can  be  used  to  identify  the  matching  TDM  slot.  The  ATM/AAL  overhead  of  this 
protocol  is  the  ATM  cell  header,  one  octet  AAL-CU  structure  offset  pointer  (to  point  to 
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the  start  of  a  channel  frame)  per  cell  and  the  AAL-CU  header  per  channel  frame.  The 
offset  pointer  is  required  as  the  channel  frames  are  not  synchronised  to  always  start  at 
the  beginning  of  a  cell.  Only  if  the  next  channel  frame  is  not  formed  within  an 
acceptable  delay  of  the  current  channel  the  last  cell  will  be  transmitted  with  padding. 
For  the  purposes  of  this  study,  I  have  assumed  that  there  will  be  no  instances  of 
padding  being  required. 

Because  of  the  offset  pointer,  the  number  of  octets  per  cell  is  47.  The  number  of  53  octet 
cells  produced  by  AAL-CU  is: 

(3  +  (channel  frame  size  in  octets)  *  (number  of  channels)  )/4 7 

The  rate  at  which  channel  frames  are  produced  is  the  individual  channel  rate  divided 
by  the  frame  size  per  channel.  Since  the  voice  channel  bit  rate  is  16  kbps,  the  PDU 
production  rate  is  16/frame  size  (in  bits)  k  channel  frames  per  second.  The  frame  fill 
latency  encountered  by  each  channel  is  the  inverse  of  the  figure. 

The  overall  bit  rate  of  this  AAL  is  thus  given  by  the  following: 

bits  per  cell  *  cells  per  PDU  *  PDU  production  rate  per  channel  *  number  of  channels 
(53*8)  *  ((3  +  (frame  size  in  octets)  *  (number  of  channels)  )/47)  *  (16/frame  size  in  bits) 
kbps 

(Note  the  number  of  channels  is  the  number  of  traffic  channels  plus  one  channel  for 
signalling.) 


1.2  Protocol  Performance  Comparison 

When  the  frame  for  each  channel  is  of  the  order  of  an  ATM  cell  payload  (parameters 
are  given  in  Table  A-l),  all  techniques  are  similar  in  performance  (in  order:  AAL1, 
dynamic  CES  then  AAL-CU).  As  seen  in  Figure  A-2,  until  the  trunk  load  exceeds  25 
(for  AAL-CU),  27  (for  dynamic  CES  and  AAL1)  the  ATM  techniques  are  more 
bandwidth  efficient  than  TDM  in  spite  of  the  overheads.  The  frame  fill  latency  is  such 
that  a  typical  worst  case  of  six  trunk  hops,  assuming  no  satellite  links,  would  remain 
below  the  150  ms  latency  quoted  by  Dutton  [8  page  8-12]  as  the  maximum  suggested 
for  voice  conversations. 
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Table  A-l  -  Voice  Protocol  Parameters 
.-.Case  One 


Parameters  (in  bits) 

32  D-CES  bitmap 

352  D-CES  frame  per  chan 

22  frame  latency  (ms) 

376  AAL1  frame 

23.5  frame  latency  (ms) 

24  AAL-CU  header 

352  AAL-CU  frame 

22  frame  latency  (ms) 


Table  A-2  -  Voice  Protocol 
Parameters  -  Case  Two 

Parameters  (in  bits) 

32  D-CES  bitmap 

80  D-CES  frame  per  chan 

5  frame  latency  (ms) 

80  AAL1  frame 

5  frame  latency  (ms) 

24  AAL-CU  header 

80  AAL-CU  frame 

5  frame  latency  (ms) 


Figure  A-2  -  Bandwidth  Requirements 
for  Each  Option  -  Case  One 


Figure  A-3-  Bandwidth  Requirements 
for  Each  Option  -  Case  Two 
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For  smaller  frames  per  call,  such  as  shown  in  Table  A-2  and  Figure  A-3,  AAL1 
becomes  unacceptably  inefficient.  For  instance  at  a  frame  latency  of  5  ms  AAL1 
exceeds  the  baseline  figure  when  more  than  5  channels  are  active.  Dynamic  CES  is  best 
performing  being  better  performing  than  the  baseline  until  more  than  27  channels  are 
active  while  the  AAL-CU  exceeds  the  baseline  after  21  channels. 


If  a  compromise  frame  fill  latency  of  10  ms  is  chosen  (Table  A-3  and  Figure  A-4)  AAL1 
is  significantly  improved  but  still  unacceptably  inefficient  exceeding  the  baseline 
figure  at  more  than  11  channels  active.  Dynamic  CES  remains  best  performing  having 
lower  bit  rate  than  the  baseline  until  more  than  27  channels  are  active  while  the  AAL- 
CU  now  exceeds  the  baseline  at  more  than  23  channels. 


Table  A-3  -  Voice  Protocol  Parameters 
-  Case  Three 

Parameters  (in  bits) 

32  D-CES  bitmap 

160  D-CES  frame  per  chan 

1 0  frame  latency  (ms) 

160  AAL1  frame 

10  frame  latency  (ms) 

24  AAL-CU  header 

160  AAL-CU  frame 

10  frame  latency  (ms) 


Figure  A-4-  Bandwidth  Requirements 
for  Each  Option  -  Case  Three 


1.3  Protocol  Parameters  Selected  for  Study 

The  following  parameters  were  selected  as  a  basis  for  further  examination  in  this 
study: 

•  Dynamic  CES:  active  channel  bit  map  of  32  bits,  80  bits  per  channel  data  frame 

•  AAL1: 376  bits  per  channel  data  frame 

•  AAL-CU:  standard  AAL-CU  header  of  24  bits,  160  bits  per  channel  data  frame 
The  resultant  kbps  requirement  for  the  range  of  active  channels  is  given  in  table  A-4. 
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Table  A-4  -  Voice  Protocol  Bandwidth  Requirements  (kbps) 
Examination 


Chnls 

Dyn 

CES 

AAL1 

AAL-CU 

Chnls 

Dyn 

CES 

AAL1 

0 

24.8 

18.0 

20.7 

16 

308.2 

306.7 

1 

42.5 

36.1 

41.5 

17 

325.9 

324.8 

2 

60.2 

54.1 

62.2 

18 

343.6 

342.8 

3 

77.9 

72.2 

83.0 

19 

361.3 

360.9 

4 

95.6 

90.2 

103.7 

20 

379.1 

378.9 

5 

113.4 

108.3 

124.5 

21 

396.8 

396.9 

6 

131.1 

126.3 

145.2 

22 

414.5 

415.0 

7 

148.8 

144.3 

166.0 

23 

432.2 

433.0 

8 

166.5 

162.4 

186.7 

24 

449.9 

451.1 

9 

184.2 

180.4 

207.5 

25 

467.6 

469.1 

10 

201.9 

198.5 

228.2 

26 

485.3 

487.1 

11 

219.6 

216.5 

249.0 

27 

503.0 

505.2 

12 

237.4 

234.6 

269.7 

28 

520.8 

523.2 

13 

255.1 

252.6 

290.5 

29 

538.5 

541.3 

14 

272.8 

270.6 

311.2 

30 

556.2 

559.3 

15 

290.5 

288.7 

332.0 

Options  for  Further 

AAL-CU 

352.7 

373.5 

394.2 
415.0 

435.7 

456.5 

477.2 
498.0 

518.7 

539.5 

560.2 
581.0 

601.7 

622.5 

643.2 
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Appendix  B:  Parakeet  Trunk  Loading  Calculations 


Figure  B-l  provides  the  Parakeet  Reference  Network  used  for  the  traffic  model.  Note 
that  only  six  nodes  are  ATM  equipped  and  hence  subject  to  the  analysis. 

The  traffic  load  statistics  from  the  Parakeet  Specification  provides  figures  in  terms  of 
call  source  and  destination  and  are  not  expressed  in  terms  of  individual  trunk 
loadings.  The  figures  were  provided  as  daily  total  call  initiations  and  had  to  be 
converted  to  busy  hour  figures  using  guidance  from  the  Parakeet  Specification  (busy 
hour  was  stated  to  be  six  times  the  average  per  hour  rate). 

The  Parakeet  network  employs  flood  search  routing,  this  will  result  in  the  call  being 
connected  via  the  shortest  open  path.  For  the  purposes  of  this  analysis,  each  source- 
destination  node  pair  was  examined  and  this  traffic  was  allocated  to  a  series  of 
concatenated  trunks  following  the  shortest  path.  If  there  were  equidistant  paths,  the 
traffic  was  evenly  divided  between  the  two  alternatives. 

Once  traffic  between  the  nodes  was  allocated  to  various  trunks,  the  load  on  each  trunk 
can  be  determined.  For  the  purposes  of  this  analysis  only  trunks  between  ATM  nodes 
were  subject  to  further  consideration.  Only  the  highest  loading  trunk  was  examined  in 
the  next  portion  of  the  model. 

Traditional  queuing  statistics  (multifacility  queuing  system  from  Turban  and  Meredith 
[9]  p644)  was  then  used  to  calculate  the  probability  density  function  of  the  number  of 
calls  at  each  moment. 
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L10  25  25  25  25  25  25  20  20  20  20  20  25  40  40  150  15  15  535 

L11  30  165  195 

LI  2  15  15  15  15  15  15  5  5  5  5  5  10  10  10  160  15  320 

LI  3  15  15  15  15  15  15  5  5  5  5  5  10  10  10  10  15  160  330 

Totals  390  430  410  410  380  620  230  290  335  345  345  290  420  335  465  465  505  200  360  330 


Total  Traffic  -  both  directions  -  BUSY  HOUR 
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ATM  Trunk  Loading 
calls  per  busy  hour 


A1 

L6/S6 

69.375 

A2 

S6/L8 

233.125 

A3 

L6/L10 

130.625 

A4 

L8/L10 

154 

A5 

L9/L10 

157.75 

A6 

L10/L11 

130.125 

A7 

LI  0/L1 3 

85 

A8 

L8/L9 

224.375 

A9 

L9/L11 

130.625 

Applying  statistical  analysis 


Channel 

Utilization 


30  number  of  channels  (K) 

233.125  mean  arrival  rate  per  hour 

3  mean  call  holding  time  in  minutes 


3.885417  mean  arrival  rate  per 
minute  (lambda) 

0.333333  mean  service  rate  per 
minute  (mu) 

1 1 .65625  utilization  factor  for  each 
channel  (ro) 

0.388542  utilization  factor  for 
system  (ro_barred) 


8.66E-06  probability  of  no  calls 

[P(0)1 
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Appendix  C:  Call  Activity  Calculations 

A  spreadsheet  was  developed  to  determine  the  bandwidth  used  given  the  probability 
distribution  of  call  connection  activity.  The  probability  density  function  derived  from 
the  traffic  analysis  was  used  in  conjunction  with  the  table  of  bit  rate  per  number  of 
connections  carried  which  was  calculated  based  on  the  AAL  design.  The  weighted 
average  bit  rate  can  then  be  calculated.  The  spreadsheet  is  represented  in  the  table 
given  below: 


Table  C-l:  Calculation  of  Effective  Bitrate  Given  Parakeet  Call  Activity 


Bit  Rate 
for  no. 
of  Chnl 
(kbps) 


Chnls  TDM 

Dyn  CES  AAL1 

AAL- 

CU 

P(N) 

TDM 

Dyn 

CES 

AAL1 

AAL- 

CU 

0 

512.0 

24.8 

18.0 

20.7 

0.00 

0.0 

0.0 

0.0 

0.0 

1 

512.0 

42.5 

36.1 

41.5 

0.00 

0.1 

0.0 

0.0 

0.0 

2 

512.0 

60.2 

54.1 

62.2 

0.00 

0.3 

0.0 

0.0 

0.0 

3 

512.0 

77.9 

72.2 

83.0 

0.00 

1.2 

0.2 

0.2 

0.2 

4 

512.0 

95.6 

90.2 

103.7 

0.01 

3.4 

0.6 

0.6 

0.7 

5 

512.0 

113.4 

108.3 

124.5 

0.02 

8.0 

1.8 

1.7 

1.9 

6 

512.0 

131.1 

126.3 

145.2 

0.03 

15.5 

4.0 

3.8 

4.4 

7 

512.0 

148.8 

144.3 

166.0 

0.05 

25.7 

7.5 

7.3 

8.3 

8 

512.0 

166.5 

162.4 

186.7 

0.07 

37.5 

12.2 

11.9 

13.7 

9 

512.0 

184.2 

180.4 

207.5 

0.09 

48.6 

17.5 

17.1 

19.7 

10 

512.0 

201.9 

198.5 

228.2 

0.11 

56.6 

22.3 

21.9 

25.2 

11 

512.0 

219.6 

216.5 

249.0 

0.12 

60.0 

25.7 

25.4 

29.2 

12 

512.0 

237.4 

234.6 

269.7 

0.11 

58.3 

27.0 

26.7 

30.7 

13 

512.0 

255.1 

252.6 

290.5 

0.10 

52.2 

26.0 

25.8 

29.6 
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14 

512.0 

272.8 

270.6 

311.2 

0.08 

43.5 

23.2 

23.0 

26.4 

15 

512.0 

290.5 

288.7 

332.0 

0.07 

33.8 

19.2 

19.1 

21.9 

16 

512.0 

308.2 

306.7 

352.7 

0.05 

24.6 

14.8 

14.8 

17.0 

17 

512.0 

325.9 

324.8 

373.5 

0.03 

16.9 

10.7 

10.7 

12.3 

18 

512.0 

343.6 

342.8 

394.2 

0.02 

10.9 

7.3 

7.3 

8.4 

19 

512.0 

361.3 

360.9 

415.0 

0.01 

6.7 

4.7 

4.7 

5.4 

20 

512.0 

379.1 

378.9 

435.7 

0.01 

3.9 

2.9 

2.9 

3.3 

21 

512.0 

396.8 

396.9 

456.5 

0.00 

2.2 

1.7 

1.7 

1.9 

22 

512.0 

414.5 

415.0 

477.2 

0.00 

1.1 

0.9 

0.9 

1.1 

23 

512.0 

432.2 

433.0 

498.0 

0.00 

0.6 

0.5 

0.5 

0.6 

24 

512.0 

449.9 

451.1 

518.7 

0.00 

0.3 

0.2 

0.2 

0.3 

25 

512.0 

467.6 

469.1 

539.5 

0.00 

0.1 

0.1 

0.1 

0.1 

26 

512.0 

485.3 

487.1 

560.2 

0.00 

0.1 

0.1 

0.1 

0.1 

27 

512.0 

503.0 

505.2 

581.0 

0.00 

0.0 

0.0 

0.0 

0.0 

28 

512.0 

520.8 

523.2 

601.7 

0.00 

0.0 

0.0 

0.0 

0.0 

29 

512.0 

538.5 

541.3 

622.5 

0.00 

0.0 

0.0 

0.0 

0.0 

30 

512.0 

556.2 

559.3 

643.2 

0.00 

0.0 

0.0 

0.0 

0.0 

effec-  512.0  231.3  228.3  262.6 

five 

band¬ 

width: 
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19.  ABSTRACT 

The  introduction  of  Asynchronous  Transfer  Mode  (ATM)  into  the  Australian  Army  tactical 
communication  system  will  provide  significant  benefits  through  responsive  network  management  and 
the  integration  of  multiple  communication  applications.  ATM  integration  into  Parakeet  is  complicated 
as  the  current  network  employs  military  standard  protocols  which  are  quite  different  to  civil  standards. 
This  report  seeks  to  quantify  capacity  economies  which  can  be  achieved  through  the  development  of  an 
adaptive  approach  to  voice  services  on  the  ATM  network  by  transmitting  only  active  connections.  An 
examination  is  also  made  to  determine  whether  data  communications  protocols  can  access  the  released 
capacity.  The  study  finds  that  savings  are  significant  and  the  released  capacity  should  add  substantially 
to  data  communications  capability. 
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